\documentclass[11pt,leqno]{article}

\usepackage[utf8]{inputenc}
\usepackage{polski}
\usepackage{a4wide}
\usepackage{graphicx}
\usepackage{fancyhdr}

\usepackage{amsmath,amssymb}
\usepackage{bbm}
\usepackage{amsthm}

\setlength{\headheight}{14pt}

\pagestyle{fancy}
\lhead{UniLANChat}
\rhead{Podręcznik programisty}

\usepackage[
pdfborder={0,0,0},
pdftitle={UniLANChat - podrecznik programisty},
pdfauthor={Tomasz Wasilczyk},
pdfdisplaydoctitle=true
]{hyperref}

\def\changemargin#1{\list{}{\rightmargin#1\leftmargin#1}\item[]}
\let\endchangemargin=\endlist 

\makeatletter
	\renewcommand\@seccntformat[1]{\csname the#1\endcsname.\quad}
	\renewcommand\numberline[1]{#1.\hskip0.7em}
	\newcommand\BSLASH{\char`\\}
\makeatother

\author{Tomasz Wasilczyk, Piotr Gajowiak}
\title{UniLANChat -- podręcznik programisty}

\begin{document}

\pagenumbering{alph}
\begin{titlepage}
\begin{center}
	\vspace*{6cm}
	\textsc{\LARGE UniLANChat}\\[0.25cm]
	\textsc{\Large Podręcznik programisty}\\[1cm]
	Tomasz Wasilczyk, Piotr Gajowiak
	\vfill
	\today
\end{center}
\end{titlepage}
\pagenumbering{arabic}

\tableofcontents

\section{Wstęp}
UniLANChat to (docelowo) wieloprotokołowy, wieloplatformowy i wielojęzykowy klient
czatów p2p\footnote{patrz: \nameref{sec:dictionary}}.
Program powstał w celu zastąpienia komunikatora IP Messenger, używanego między innymi w akademikach
Uniwersytetu Wrocławskiego. Podstawowe założenia:
\begin{itemize}
	\item zgodność z protokołem IP Messenger, komunikatory powinny ze sobą współdziałać w ramach tej
	samej sieci;
	\item program powinien dobrze działać zarówno pod systemem Windows, jak i Linux -- napisany jest
	więc w JavaSE;
	\item ergonomiczny interfejs użytkownika, wzorowany jest na komunikatorze Pidgin;
	\item udostępniony na otwartej licencji LGPL;
	\item obsługa wielu języków (w przyszłych wersjach).
\end{itemize}

Pierwowzór odbiegał od części z powyższych założeń -- interfejs jest w nim jeszcze z czasów
Windows 3.11, a jego działanie pod systemem Linux pozostawia wiele do życzenia.

\vspace{1cm}
W miarę możliwości czasowych, być może będą realizowane następujące cele dodatkowe:
\begin{itemize}
	\item zgodność z innymi protokołami, np. LanChat, winpopup;
	\item różne interfejsy użytkownika: graficzny, tekstowy dla konsoli (czyli okienka ASCII) oraz
	tekstowy dla terminala (np. do obsługi standardowymi strumieniami);
	\item protokół automatycznego routingu: sieć p2p sama mogła by dbać, aby różni klienci,
	którzy nie posiadają bezpośredniego połączenia, mogli ze sobą rozmawiać (per proxy, przez innych
	użytkowników sieci);
	\item komunikacja głosowa;
	\item całkowicie zdecentralizowana sieć wymiany plików p2p.
\end{itemize}

\subsection{Autorzy}

Autorzy programu:
\begin{itemize}
	\item Tomasz Wasilczyk (\href{http://www.wasilczyk.pl}{www.wasilczyk.pl}),
	\item Piotr Gajowiak.
\end{itemize}

Strona projektu: \href{http://unilanchat.googlecode.com}{unilanchat.googlecode.com}

Projekt powstał (do wersji 0.2.1) w ramach licencjackiego projektu
programistycznego, prowadzonego w Instytucie Informatyki Uniwersytetu
Wrocławskiego (\href{http://www.ii.uni.wroc.pl}{www.ii.uni.wroc.pl}), pod
nadzorem dr Pawła Kellera.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Ogólna dokumentacja programistyczna}

Dokumentacja kodu źródłowego znajduje się w oddzielnym dokumencie, wygenerowanym narzędziem javadoc.

\subsection{Numeracja wersji}

Wersje programu są numerowane według schematu:
\[
<major>.<minor>[.<release>][ (nightly)]
\]
gdzie:
\begin{itemize}
	\item \textbf{major} -- główny numer wersji programu, związany z bardzo znaczącymi zmianami.
	Zaczyna się od 0 (wersja testowa), następne są wersjami przeznaczonymi dla użytkowników
	końcowych;
	\item \textbf{minor} -- kolejne wydania programu, wprowadzają nowe funkcje, lub znaczne
	poprawki błędów. Numeracja może być wielocyfrowa, zaczyna się od liczby
	1 w przypadku gałęzi 0.x oraz od 0 w przypadku kolejnych;
	\item \textbf{release} -- drobne poprawki, które nie zostały uwzględnione w wydaniu minor,
	ale wymagające szybkiej naprawy, np. poprawki bezpieczeństwa, lub błędów
	uniemożliwiających korzystanie z programu. Wersja 0 nie jest dodawana
	do ciągu oznaczającego pełny numer wersji;
	\item \textbf{nightly} -- kompilacja zrzutu z svn. Jest to wersja kandydująca do tej bez
	oznaczenia nightly, zazwyczaj do wydania wersji finalnej się znacznie
	zmienia. Nie jest przeznaczona dla użytkowników końcowych, ani betatesterów.
\end{itemize}

\subsection{Zasady formatowania}
\begin{itemize}
	\item wcięcia tabulacjami;
	\item pusta linia na końcu pliku, bez białych znaków na końcach linii (również pustych);
	\item klamry otwierające i zamykające w nowej linii, w tej samej kolumnie co blok
	nadrzędny, blok podrzędny wcięty o jedną tabulację;
	\item komentarze javadoc:
	\begin{itemize}
		\item opis metody z dużej litery, zakończony kropką;
		\item opisy parametrów i zwracanych wartości z małej litery, bez kropki na końcu;
		\item deklaracje zwracanych wartości boolean:
		\texttt{@return <code>true</code>, jeżeli (...)};
	\end{itemize}
	\item importowane paczki w dwóch oddzielonych pustą linią sekcjach: java[x] oraz reszta.
\end{itemize}

\subsection{Struktura aplikacji}

UniLANChat składa się z następujących komponentów:
\begin{itemize}
	\item program działający w maszynie wirtualnej Javy, którego kod źródłowy znajduje się
	w katalogu \texttt{java};
	\item biblioteki JNI\footnote{patrz: \nameref{sec:dictionary}}, wykorzystywane przez
	powyższy program, których kod źródłowy jest w katalogu \texttt{jni}. Aby uprościć proces
	kompilacji projektu (oraz zmniejszyć wymagane zależności), te biblioteki są dostarczane
	w postaci binarnej (dla wszystkich obsługiwanych platform) z możliwością ich rekompilacji;
	\item natywnych programów startowych (znajdujących się w katalogu \texttt{launcher}) dla
	systemów Windows oraz Linux. Pierwszy z nich jest generowany programem
	launch4j (\href{http://launch4j.sourceforge.net}{launch4j.sourceforge.net}), drugi jest skryptem w bashu.
\end{itemize}

\subsection{Zarys przepływu danych}

W programie wykorzystano wzorzec MVC, w związku z czym\footnote{w Internecie krąży wiele
sprzecznych interpretacji tego wzorca -- aby uniknąć nieporozumień, zostanie to tutaj uściślone}:
\begin{itemize}
	\item \textbf{model} przechowuje pełne dane na temat implementowanych rozwiązań, np. treść
	wiadomości, jej autora, datę odebrania. Nie ma jednak możliwości bezpośredniego oddziaływania
	na widok, ani kontroler (chyba, że tamte go obserwują);
	\item \textbf{widok} służy do wyświetlania danych z modelu oraz wywoływania odpowiednich metod
	kontrolera, w celu operowania na danych. Widok nie powinien modyfikować bezpośrednio modelu;
	\item \textbf{kontroler} odpowiada za wykonywanie akcji zleconych przez widok, a także
	przechowywanie wygenerowanych obiektów z modelu (czyli np. listy użytkowników, listy pokoi
	rozmów). Kontroler nie może bezpośrednio modyfikować widoku, ale może na niego oddziaływać
	przez wzorzec obserwatora.
\end{itemize}

Wzorzec obserwatora pozwala na przekazywanie informacji do obiektów, nad którymi obserwowany
obiekt nie ma kontroli. Np. model kontaktu (osoby na liście kontaktów) sam w sobie nie może
modyfikować widoku listy kontaktów, ale jest przez nią obserwowany\footnote{w rzeczywistości model kontaktu
jest obserwowany przez model listy kontaktów, a ta dopiero przez widok listy kontaktów}. Wtedy
w przypadku jego zmiany (np. zmiana statusu dostępności) wysyła o tym powiadomienie wszystkim
obserwatorom, a więc także wspomnianemu widokowi.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Protokół: IP Messenger}

Protokół jest bezpołączeniowy, opiera się o rozgłaszanie swojej obecności poprzez
broadcast\footnote{patrz: \nameref{sec:dictionary}}, za pomocą pakietów UDP. Wykorzystuje
opcjonalne szyfrowanie, transfer plików (oparty o TCP), pozwala na użycie opcjonalnego serwera
pośredniczącego.

Strona projektu: \href{http://ipmsg.org}{ipmsg.org}.

Domyślnie wykorzystywanym portem (zarówno TCP, jak i UDP) jest 2425 -- aby zachować możliwość
pełnej komunikacji, należy mieć w firewallu otworzone je także na połączenia przychodzące.

\subsection{Pakiety UDP}\label{sec:udpPackets}

Pakiety UDP są przesyłane w następującym formacie (jako czysty tekst):
\begin{verbatim}
	<wersja protokołu>:<numer pakietu>:<login nadawcy>:<host nadawcy>:
	<polecenie i flagi>:<dane>\0
\end{verbatim}
gdzie:
\begin{description}
	\item[wersja protokołu] -- ipmsg korzysta tylko z wartości \texttt{1}, a implementacja
	iptux -- \texttt{1\_iptux\_0};
	\item[numer pakietu] (w formacie dziesiętnym) -- unikalny (w skali każdego rozmówcy, z którym
	wymieniamy pakiety) identyfikator pakietu, dzięki któremu można realizować m.in. kontrolę
	dostarczania wiadomości. W oryginalnym kliencie jest inicjowany wartością
	unix timestamp\footnote{patrz: \nameref{sec:dictionary}}, w UniLANChat losową;
	\item[login nadawcy] -- w oryginalnej implementacji jest to login zalogowanego
	użytkownika w systemie nadawcy. W implementacji UniLANChat jest to po prostu jego nick (nie
	chcemy zdradzać wspomnianej nazwy użytkownika);
	\item[host nadawcy] -- nazwa hostu nadawcy;
	\item[polecenie i flagi] (w formacie dziesiętnym) -- przechowuje zarówno identyfikator polecenia, jak i jego
	flagi. Aby się do nich odwołać, należy wykonać operacje bitową AND z wartościami:
	\begin{itemize}
		\item \texttt{0x000000FF} -- identyfikator polecenia (opisane w klasie \texttt{IpmsgPacket},
		w pakiecie \texttt{protocols.ipmsg}, tam też znajdują się ich kody);
		\item \texttt{0xFFFFFF00} -- flagi bitowe, wykorzystywane zależnie od polecenia (opisane j/w);
	\end{itemize}
	\item[dane] zależne od konkretnego identyfikatora polecenia (np. treść wiadomości,
	dane n/t klucza itp.), mogą zawierać kolejne separatory (dwukropki);
	\item[\textbackslash0] -- znak null.
\end{description}

\subsubsection{\textnormal{\texttt{NOOP}} -- pusty pakiet}

Pusty pakiet, nie udało nam się odkryć jego zastosowania. Nie obsługuje żadnych flag, ani sekcji
danych.

%%% Powiadamianie o obecności %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsubsection{\textnormal{\texttt{ENTRY}} -- powiadomienie o obecności}

Rozpoczęcie sesji, lub odświeżenie listy. Może być wysyłany zarówno na adres broadcast (aby
powiadomić wszystkich o swojej obecności), jak i pojedyńcze adresy (aby sprawdzić ich dostępność).
Odebranie takiego pakietu powoduje dodanie nadawcy do listy kontaktów oraz wysłanie mu odpowiedzi
\texttt{ANSENTRY}.

Flagi:
\begin{itemize}
	\item \texttt{ABSENCE} -- nadawca pakietu ma ustawiony status \textit{zaraz wracam};
	\item \texttt{SERVER} -- zarezerwowany;
	\item \texttt{DIALUP} -- oznacza to, że nadawca nie może odbierać wiadomości broadcast.
	Należy wysyłać do niego takie wiadomości indywidualnie (UniLANChat i tak korzysta
	z unicastu\footnote{patrz: \nameref{sec:dictionary}}, kiedy tylko się da);
	\item \texttt{FILEATTACH};
	\item \texttt{ENCRYPT}.
\end{itemize}

Sekcja danych:
\begin{verbatim}
	<nick>[opis]\0<grupa>
\end{verbatim}
gdzie:
\begin{description}
	\item[nick] -- konfigurowalny alias użytkownika, do wyświetlenia na liście kontaktów;
	\item[opis] -- status opisowy użytkownika;
	\item[grupa] -- grupa, do której należy użytkownik (także wybierana przez niego).
\end{description}

\subsubsection{\textnormal{\texttt{EXIT}} -- powiadomienie o opuszczeniu sieci}

Powiadomienie innych użytkowników sieci o jej opuszczeniu przez nadawcę. Po otrzymaniu
takiego pakietu należy usunąć nadawcę z listy kontaktów. Flagi i sekcja danych jest
taka sama, jak w \texttt{ENTRY}.

\subsubsection{\textnormal{\texttt{ANSENTRY}} -- potwierdzenie obecności}

Potwierdzenie odebrania pakietu \texttt{ENTRY}. Nasłuchiwanie tych pakietów jest
wykorzystywane do uzupełnienia listy obecności nowych użytkowników.
Flagi i sekcja danych jest taka sama, jak w \texttt{ENTRY}.

\subsubsection{\textnormal{\texttt{ABSENCE}} -- powiadomienie o zmianie statusu}

Powiadomienie o zmianie statusu. Flagi i sekcja danych jest taka sama, jak w \texttt{ENTRY}.
Zasadniczą różnicą między \texttt{ABSENCE} a \texttt{ENTRY} jest nie wysyłanie pakietu
\texttt{ANSENTRY} po otrzymaniu tego pierwszego.

%%% Przesyłanie wiadomości %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsubsection{\textnormal{\texttt{SENDMSG}} -- wysłanie wiadomości}\label{sec:udpPackets:sendMsg}

Pakiet z wysyłaną wiadomością, może zawierać także informacje o załącznikach (które są później
przesyłane osobnym kanałem). Wiadomość może być szyfrowana (format w tej chwili nie jest tutaj
opisany).

Flagi:
\begin{itemize}
	\item \texttt{SENDCHECK} -- nadawca oczekuje na potwierdzenie dostarczenia wiadomości
	(\texttt{RECVMSG}), jeżeli ono nie dojdzie, wiadomość jest wysyłana ponownie;
	\item \texttt{SECRET} -- wiadomość jest zapieczętowana, w implementacji UniLANChat ignorowana;
	\item \texttt{READCHECK} -- nadawca zostanie poinformowany o próbie otworzenia wiadomości,
	używana razem z SECRET. W implementacji UniLANChat ignorowana;
	\item \texttt{BROADCAST} -- wiadomość do wszystkich obecnych w sieci. Na takie pakiety nie są
	odsyłane potwierdzenia odbioru. Oryginalna implementacja IPMsg korzysta z tej flagi także dla
	pakietów, które są rozsyłane tylko do wybranej grupy odbiorców;
	\item \texttt{MULTICAST} -- wiadomość do wybranej grupy odbiorców. Na te pakiety są odsyłane
	potwierdzenia odbioru. Ta flaga jest używana w implementacji UniLANChat dla wszystkich grupowych
	rozmów (ze względu na wspomniane potwierdzenia odbioru);
	\item \texttt{MULTICAST\_NEW} -- odpowiednik \texttt{MULTICAST}, ale zarezerwowany dla przyszłych
	wersji protokołu;
	\item \texttt{NOPOPUP} -- flaga nieprawidłowa w wersji protokołu Draft-9, ignorowana;
	\item \texttt{AUTORET} -- flaga oznaczająca, że odpowiedź jest automatyczna. Jest to
	zabezpieczenie przed efektem "ping-pong", między dwoma osobami z ustawioną automatyczną
	informacją o nieobecności;
	\item \texttt{RETRY};
	\item \texttt{PASSWORD} -- flaga zapieczętowania i zabezpieczenia hasłem (ignorowana).
	W oryginalnej implementacji ipmsg użytkownik przed odpieczętowaniem (i przeczytaniem
	wiadomości) musi podać swoje hasło, ustawione wcześniej w programie (domyślnie puste);
	\item \texttt{NOLOG} -- flaga sugerująca, aby nie zapisywać danej wiadomości
	w logu (ignorowana);
	\item \texttt{NOADDLIST}.
\end{itemize}

Sekcja danych:
\begin{verbatim}
	<treść wiadomości>[\0<<numer pliku>:<nazwa pliku>:<rozmiar pliku>:
	<czas ostatniej modyfikacji>:<atrybut>
	<:dodatkowy atrybut=wartość<,wartość>*>*:\b:>+]
\end{verbatim}
gdzie:
\begin{description}
	\item[treść wiadomości] -- treść przesyłanej wiadomości, może być pusta;
	\item[numer pliku] -- numer pliku w obrębie pakietu, w którym jest inicjowane
	jego wysyłanie;
	\item[nazwa pliku] -- nazwa pliku, jeśli w nazwie występuje znak ':' należy go zastąpić przez '::';
	\item[rozmiar pliku] -- rozmiar pliku, dla folderu oryginalny klient ustawia
	to pole równe 0, w implementacji UniLANChat jest to suma długości wszystkich
	plików znajdujących się w folderze;
	\item[atrybut] -- jedna z wartości:
	\begin{description}
		\item[\textnormal{\texttt{FILE\_REGULAR}}] -- plik właściwy;
		\item[\textnormal{\texttt{FILE\_DIR}}] -- folder;
	\end{description}
	\item[dodatkowy atrybut] -- dodatkowe informacje o pliku;
	\item[wartość] -- jedna z wartości dodatkowego atrybutu.
	\item[\textbackslash b] -- znak Bell, kod ASCII o numerze 7.
\end{description}

\subsubsection{\textnormal{\texttt{RECVMSG}} -- potwierdzenie odebrania wiadomości}

Potwierdzenie odebrania wiadomości informuje odbiorcę, że wiadomość przez niego wysłana została
odebrana.

Sekcja danych: identyfikator pakietu z potwierdzaną wiadomością (w formacie dziesiętnym).

%TODO: flagi

\subsubsection{\textnormal{\texttt{READMSG}} -- potwierdzenie przeczytania wiadomości}

Potwierdzenie otworzenia zapieczętowanej wiadomości (pakiet ignorowany) -- jeżeli 
w wiadomości (\texttt{SENDMSG}) była ustawiona flaga \texttt{READCHECK}.

%TODO: flagi, sekcja danych

\subsubsection{\textnormal{\texttt{DELMSG}} -- powiadomienie o odrzuceniu wiadomości}

Odpowiednik \texttt{READMSG}, ale informujący o odrzuceniu wiadomości.

%TODO: flagi, sekcja danych

\subsubsection{\textnormal{\texttt{ANSREADMSG}} -- potwierdzenie odebrania \textnormal{\texttt{READMSG}} lub \textnormal{\texttt{DELMSG}}}

Potwierdzenie odebrania pakietów \texttt{READMSG} lub \texttt{DELMSG}, działa podobnie do
\texttt{RECVMSG}. Pakiet ignorowany.

%TODO: flagi, sekcja danych

%%% Wymiana kluczy RSA %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%\subsubsection{\textnormal{\texttt{GETPUBKEY}} -- zapytanie o klucz publiczny RSA}
%\subsubsection{\textnormal{\texttt{ANSPUBKEY}} -- przesłanie klucza publicznego RSA}

\subsection{Nagłówki strumieni TCP}\label{sec:tcpHeaders}

Nagłówki strumieni TCP mają tą samą strukturę jak te opisane w sekcji \nameref{sec:udpPackets} z
wyjątkiem nagłówka kontrolującego wysyłanie folderów.

Sekcja danych:

\begin{verbatim}
	<numer pakietu>:<numer pliku>[:domiar]:
\end{verbatim}

gdzie:
\begin{description}
	\item[numer pakietu] -- numer pakietu, który inicjował wysyłanie danego pliku;
	\item[numer pliku] -- numer pliku, z pakietu inicjującego identyfikowanego przez numer pliku;
	\item[domiar] -- liczba początkowych bajtów, która ma zostać pominięta podczas wysyłania,
	występuje jedynie w przypadku polecenia \texttt{GETFILEDATA} i jest wtedy polem wymaganym.
\end{description}
Wszystkie powyższe wartości są zapisane w systemie szesnastkowym.

\subsubsection{\textnormal{\texttt{GETFILEDATA}} -- odbieranie pliku}

Wysyłany, gdy użytkownik żąda od serwera wysłania pliku.

\subsubsection{\textnormal{\texttt{GETDIRFILES}} -- odbieranie folderu}

Wysyłany, gdy użytkownik żąda od serwera wysłania folderu.

\subsubsection{Nagłówek kontrolujący wysyłanie folderów}\label{sec:hierarchicalFileHeader}

\begin{verbatim}
	<rozmiar nagłówka>:<nazwa pliku>:<rozmiar pliku>:
	<atrybut><:dodatkowy atrybut=wartość<,wartość>*>*:<dane>
\end{verbatim}

gdzie:
\begin{description}
	\item[rozmiar nagłówka] -- rozmiar nagłówka w bajtach, liczony aż do ostatniego bajtu przed danymi;
	\item[nazwa pliku] -- nazwa pliku, jeśli w nazwie występuje znak ':' należy go zastąpić przez '::';
	\item[rozmiar pliku] -- oznacza rozmiar pliku w bajtach, określa jednocześnie długość pola dane;
	\item[atrybut] -- jedna z wartości:
	\begin{description}
		\item[\textnormal{\texttt{FILE\_REGULAR}}] -- plik właściwy;
		\item[\textnormal{\texttt{FILE\_DIR}}] -- folder;
		\item[\textnormal{\texttt{FILE\_RETPARENT}}] -- nakaz powrotu do katalogu nadrzędnego,
		używany odczas przechodzenia drzewa katalogów;
	\end{description}
	\item[dodatkowy atrybut] -- dodatkowe informacje o pliku;
	\item[wartość] -- jedna z wartości dodatkowego atrybutu;
	\item[dane] -- dane z pliku, o długości równej polu rozmiar pliku.
\end{description}
Wszystkie powyższe wartości są zapisane w systemie szesnastkowym z wyjątkiem nazwy pliku oraz danych.

\subsection{Scenariusze komunikacji}

\subsubsection{Przyłączenie do sieci, odświeżenie listy kontaktów}

\begin{enumerate}
	\item Klient wysyła na adres broadcast pakiet \texttt{NOOP} (tylko w oryginalnej
	implementacji);
	\item klient wysyła na adres broadcast pakiet \texttt{ENTRY};
	\item inni klienci, którzy otrzymają powyższy pakiet, odsyłają na adres nadawcy
	pakiet \texttt{ANSENTRY}.
\end{enumerate}

UniLANChat dodatkowo, każdemu kontaktowi ze swojej listy, który nie odpowie na ten pakiet,
wysyła pakiet \texttt{ENTRY} na adres unicast.

\subsubsection{Opuszczenie sieci}

Wykonywane dwukrotnie, aby zwiększyć pewność, że wszyscy otrzymają tą informację:
\begin{enumerate}
	\item Klient wysyła na adres broadcast pakiet \texttt{NOOP} (tylko w oryginalnej
	implementacji);
	\item klient wysyła na adres broadcast pakiet \texttt{EXIT}.
\end{enumerate}

\subsubsection{Ustawienie statusu}

UniLANChat wykorzystuje to także do ustawienia statusu opisowego (technicznie -- zmiany nicka).
\begin{enumerate}
	\item Klient wysyła na adres broadcast pakiet \texttt{NOOP} (tylko w oryginalnej
	implementacji);
	\item klient wysyła na adres broadcast pakiet \texttt{ABSENCE}.
\end{enumerate}

\subsubsection{Wysłanie wiadomości nieszyfrowanej}\label{sec:scenario:message}

\begin{enumerate}
	\item Nadawca pliku wysyła do odbiorcy pakiet \texttt{SENDMSG}, z wiadomością;
	\item odbiorca odsyła nadawcy pakiet \texttt{RECVMSG};
	\item jeżeli nadawca w określonym czasie nie otrzyma pakietu z potwierdzeniem,
	ponawia próbę wysłania.
\end{enumerate}

\subsubsection{Przesyłanie plików}

\begin{enumerate}
	\item Nadawca pliku wysyła do odbiorcy wiadomość (patrz \nameref{sec:scenario:message})
	wraz z ustawioną flagą \texttt{FILEATTACH} oraz z sekcją danych opisaną w \nameref{sec:udpPackets:sendMsg}
	\item dla każdego pliku zawartego w sekcji danych odbiorca wykonuje jedno połączenie
	do nadawcy używając protokołu TCP na domyślnym porcie. Wysyła pakiet \texttt{GETFILEDATA}
	w przypadku odbierania pliku właściwego, albo \texttt{GETDIRFILES} w przypadku folderu
	z sekcją danych opisaną w \nameref{sec:tcpHeaders} na początek strumienia TCP i oczekuje na
	napływające dane.
	\item nadawca odczytuje żądanie wysłania pliku ze strumienia, odnajduje go na swojej liście plików oczekujących
	na wysłanie i zależnie od rodzaju przesyłanego pliku wysyła dane na dwa sposoby:
	\begin{itemize}
		\item jeśli żądanie dotyczyło pliku właściwego to kopiuje dane pliku bajt po bajcie do
		strumienia TCP. Komunikacja kończy się wraz z ostatnim wysłanym bajtem
		\item jeśli żądanie dotyczyło folderu to przechodzi drzewo katalogu algorytmem DFS\footnote{patrz: \nameref{sec:dictionary}}
		wypisując nagłówki opisane w \nameref{sec:hierarchicalFileHeader} do strumienia TCP
		pamiętając o następujących zasadach:
		\begin{itemize}
			\item jako pierwszy wypisywany jest nagłówek \texttt{FILE\_DIR} dla
			katalogu, który jest wysyłany
			\item wchodząc katalog niżej wypisywany jest nagłówek \texttt{FILE\_DIR} dla katalogu,
			który jest właśnie odwiedzany
			\item napotykając na plik wypisywany jest nagłówek \texttt{FILE\_REGULAR}
			wraz z danymi tego pliku w polu dane
			\item wychodząc z rekursji wypisywany jest nagłówek \texttt{FILE\_RETPARENT}
		\end{itemize}
		odbiorca rekonstruuje drzewo katalogu odczytując nagłówki wraz z danymi,
		wykonując symetryczne akcje do każdego z nagłówków. Komunikacja kończy się, gdy
		zostanie wypisany nagłówek \texttt{FILE\_RETPARENT} wychodzący z katalogu
		będącego korzeniem drzewa DFS
	\end{itemize}
\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Słownik pojęć} \label{sec:dictionary}

\begin{description}
	\item[broadcast] -- rozsyłanie jednego pakietu do wszystkich znajdujących się w sieci
	komputerów.
	\item[czat p2p] -- protokół rozmów tekstowych w sieci bez pośrednictwa serwera, w której każdy
	z użytkowników trzyma lokalnie listę wszystkich uczestników rozmowy.
	\item[JNI, Java Native Interface] -- metoda pozwalająca w programach napisanych w Javie używać
	kodu natywnego, czyli kompilowanego dla konkretnego typu maszyny. Pozwala to korzystać z innych
	języków programowania, takich jak C++.
	\item[unicast] -- przeciwieństwo \textit{broadcast}u, czyli wysłanie jednego pakietu do jednego
	odbiorcy.
	\item[unix timestamp] -- czas reprezentowany jako liczba sekund od 1 stycznia 1970, godz. 0:00.
	\item[DFS] -- algorytm przechodzenia grafu w głąb, czyli przeszukiwanie zaczyna się
	od korzenia i przechodzi w dół do gałęzi, a następnie cofa się o jeden poziom w górę
	i przeszukuje kolejnego potomka bieżącego węzła.
\end{description}


\end{document}
